들어가며

NHN이 무슨 회사인지 사실 잘 몰랐는데, 이렇게 많은 비즈니스를 가진 회사인 줄은 더더욱 몰랐습니다.

현장에서 받아적은 메모를 정리해둡니다.

마이크로 프론트엔드

두레이 메인 서비스 리뉴얼 프로젝트에 대한 세션이었습니다.

어떤 상황이었나

기존은 React 기반의 Monolithic SPA였고, 스택은 다음과 같았습니다.

• 모노레포 (yarn workspace)
• React (TypeScript)
• Vite
• Redux Toolkit

무슨 문제를 느꼈나

• 서비스가 점점 복잡해지고, 모든 도메인 지식을 다 섭렵하기 어려움
• 서비스에 대한 오너십 부재
• 커다란 또 하나의 레거시 시스템이 될 것 같음
• 소스코드가 방대해지고 빌드 시간이 늘어남

그래서 나온 발상이 이것이었습니다.

따로 테스트하고, 빌드하고, 배포하고, QA까지 마친 뒤에 런타임에 합쳐지면 어떨까?

대안 1 — Linked SPA

여러 SPA를 링크로 이어 붙이는 방식입니다.

하지만 이 방식은 채택되지 않았습니다. 이유가 인상적이었습니다.

두레이는 웹 앱이다. 웹사이트가 아니다.

문서를 오가는 웹사이트라면 페이지 이동이 자연스럽지만, 앱처럼 쓰는 서비스에서 매번 문서가 갈아끼워지는 건 맞지 않는다는 이야기였습니다.

대안 2 — Unified SPA

결국 선택된 방향입니다. 핵심 키워드는 App Shell이었습니다.

애플리케이션 셸을 하나 두고, 주소창으로 들어오는 모든 요청을 하위 서비스로 라우팅해주는 구조입니다. 페이지 단위로 나눠서 개발하되, 사용자 입장에서는 하나의 앱으로 보입니다.

메모에는 이 갈래를 구분하는 키워드들이 함께 적혀 있습니다.

Linked Pages / Linked SPAs / Unified SPA / Unified SPAs

무엇을 어디까지 쪼개고 무엇을 공유할 것인가에 따라 이렇게 나뉜다는 취지였는데, 각각의 정확한 경계는 따로 찾아봐야 할 것 같습니다.

디자인 시스템

인상 깊었던 문장이 있었습니다.

개별 피처의 완성도에 집중하기보다, 컴포넌트를 통해 빠른 테스트 환경을 제공해서 진정한 유저 밸류를 찾는 데 포커스를 둔다.

디자인 시스템을 “예쁘게 통일하기”가 아니라 “빠르게 시험해보기 위한 도구” 로 보고 있다는 점이 달랐습니다.

• 일관적인 용어 사용 → 생산성의 증가
• 하나의 공통된 디자인 라이브러리를 개발

용어 이야기가 특히 그랬습니다. 같은 것을 팀마다 다르게 부르면, 그 차이를 매번 번역하는 비용이 계속 발생한다는 이야기입니다.

거대한 웹앱 정리하기

무엇을 나눌 것인가

• 디자인적인 요소 — 색, 타이포그래피, 쉐도우
• 기능적인 요소 — 버튼 등

그리고 그 위에 디폴트 컴포넌트를 둡니다.

상태와 비동기

스토어에서 액션 시 미들웨어를 사용해 비동기를 처리하면, 컴포넌트가 언마운트될 때의 이벤트 호출 제어를 바꿀 수 있다는 내용이 있었습니다.

듣고 나서 든 의문들

세션을 들으면서 계속 걸렸던 질문들을 적어둡니다. 아직 답을 못 찾았습니다.

상태를 모두 스토어에 두는 게 맞을까?

그렇게 하면 스토어가 방대해집니다. 과연 모든 상태가 스토어에 있어야 할까요? 전역 상태 관리라고 해서 모든 상태가 전역으로 관리되어야 하는 건 아닐 텐데, 로컬 스테이트로 관리하면 안 되는 걸까요.

redux-saga와 redux-thunk 중에서는?

흐름 제어에서 어떤 쪽이 더 좋을지 판단이 서지 않습니다.

메인 스레드와 워커

별도의 개념으로 일을 시키는 방법에 대해서도 더 알아봐야겠습니다.

정리

정리하면서 보니 세션마다 결이 달랐는데, 관통하는 게 하나 있었습니다. “어디까지 나누고 무엇을 공유할 것인가” 였습니다.

마이크로 프론트엔드는 배포 단위를 나누는 이야기였고, 디자인 시스템은 UI를 나누고 공유하는 이야기였고, 마지막 의문은 상태를 어디까지 나눌 것인가에 대한 것이었습니다.

당장 답을 낼 수 있는 문제는 아니지만, 지금 하는 일에도 계속 따라올 질문이라는 생각이 들었습니다.